[レポート] AWS Cloud Roadshow 2017広島：ユーザー企業のアプリ開発でクラウドメリットを享受する #awsroadshow

こんにちは、菊池です。

本日は、広島で開催されているAWS Cloud Roadshow 2017に参加してます。

• AWS Cloud Roadshow 2017 広島

導入事例トラックから、大創産業様の「ユーザー企業のアプリ開発でクラウドメリットを享受する」を聴講しましたのでレポートします。

セッション概要

• タイトル：
  • ユーザー企業のアプリ開発でクラウドメリットを享受する
• スピーカー：
  • 株式会社 大創産業 情報システム部システム企画課 課長 システム開発2課 課長 丸本 健二郎 様
• セッション概要：
  • AWS を使うことでのインフラメリットはよく聞くが、アプリ開発のメリットはなんだろう。 ユーザー企業として改善すべきアプリ開発における課題を、AWS を使ってどう解決しようとしているのか共有させていただきます。

レポート

• 会社概要（2017/3現在）
  • 売上4200億
  • 4,950店舗
  • 70,000の商品
  • 27ヶ国に展開
    • 広島だけで92店舗
    • 稚内から石垣島/宮古島まで出店
    • 小売業として国内4位の出店数
    • 東広島市に本社

ダイソーでのAWS活用事例

2014年に開発したシステムについて

• 発注業務の課題
  • 小売業のパレートの法則：売り上げの8割は売れ筋の2割の商品で成り立っている
  • 売れ筋商品を適切に発注して在庫を維持できるか?
    • 商品数
    • 新商品
    • 季節
    • 販促
  •  これら全てを把握して発注するのは難しい
  • 売り上げが伸びている店舗はうまく回っている
    • 熟練のスタッフが発注をこなしている
  • しかし、少子化に伴う人材不足 -> システムで解決したい
  • L2のAIで発注を管理
    • 効果はあるのかトライアル：50店舗で実施
    • 結果：欠品率が改善 & 売り上げ上昇 -> 人が予測するよりもよい成果が得られた
• さあ、全店に導入しよう！
  • しかし、すぐに答えることができなかった
  • 夜間の集計処理を8時間以内に完了させる必要がある
    • 現実は200店舗（国内7%）の処理で限界だった
• さあどうしよう？
  • 簡単なチューニングでは無理
  • 根本から変更することにした
• チャレンジ1：データ量
  • 店舗数 x 商品数 x 需要予測 x 拡張 = 157億件のデータ件数をどのように処理するか
• チャレンジ2：時差
  • グローバルな店舗展開ため、日本の夜間だけの考慮ではだめ（日本で間に合ってもアメリカでは間に合わない）
• チャレンジ3：水平展開
  • 27ヶ国に丸々移植していた
  • 27個のシステムを作るのではなく、1つで集中管理したい
• ソリューション比較

	オンプレの商用RDB	Redshift	EMR
処理	×	○	△
スケール	×（ACID）	○（ノードでスケール）	○（分散処理）
参照	○	○（BI）	△（Hive）

• Redshift採用を決定、無事リリース
  • 1つのシステムでグローバル全店舗を対応している

残った課題

• 描いていたゴール：自動発注システム
  • サブシステム化して柔軟な環境
• 実際はモノリシックな1つのシステムに

システム開発における課題

• 業務部門からの要件追加
  • 影響範囲が大きい、コストも大きい
  • 大きシステムは改修時のテストも大変
  • 改善効果以上に改修コストがかかる = 費用対効果が出ない
  • それでもなんとかしなくてはいけない
    • 外付けの改修でなんとかする
    • その後の改修でハマるポイントになってしまう
    • 無理な改修で損失がでることに
    • システムがスパゲッティ化
• 開発ベンダーの問題
  • 「改修にxxxx万円かかります」
  • 「今リソースないので動けません」
  • ロックイン状態に
• インフラ・DBの問題
  • 物理環境に余裕があればいいが、ないと厳しい
  • 追加の投資判断も難しい

対応：開発手法の刷新

• システムを分割
• インフラはAWSに
• システムごとにベンダーも選定
• コンウェイの法則
  • 設計チームの組織体がシステム構造と1:1になる
  • これまで：1チームに5つのシステム作らせると、結果、1つのシステム出来上がる
  • これから：5つのサブシステムを作るのであればチームも5つに分けることが必要

システム環境

• As-Is：全てを管理してた（オンプレミス）
• To-Be：フルマネージド（AWS）
• ビジネスロジックに集中して社内のリソースを投入
• しかしAWSはサービスいっぱい
  • よし！勉強しよう
  • 調査チーム立ち上げ
  • BlackBelt、Qiitaで勉強
• とあるシステム構築中に...
  • 今作ってる仕組み、すでにサービスであるじゃん！
• 結論：自分たちだけで全てのAWSサービスをカバーするのは厳しい
  • 先生（AWSパートナー）に頼む
    • 即、充実した内容でレスポンスしてくれる！
    • いくつものよい案を、クイックに安くアウトプットしてくれる！
    • 絶対、パートナー使うのがいい！
• パートナー：AWSの知識
• ダイソー：業務知識
  • それぞれの得意分野を生かし、シナジー効果を実感！

これからの思い

• どんどん新しいサービスが出てくる
• SIer時代の経験から、要求に対して120点を目指してきた
• しかし、今の120点が来年の100点とは限らない
• 変化にどれだけついていけるかが重要

まとめ

• AWSはイイ！
  • マイクロサービス：小さく、変化に強く、ダメなら捨てる
  • サービスごとにスケール：AWS環境を活用
  • ビジネスロジックに集中：リソースを集中
  • 労せず品質アップ:AWSのスペシャリストに任せる
• 変化に強くなる

まとめ

ユーザー企業として、AWSを使ったシステム開発でどう事業に繋げているかという、非常に参考になるセッションでした。これからの時代の流れに対応するため、変化に強いシステムを作っていくという点にとても共感しました。

AWSを利用すること、そしてAWSの部分はパートナーに任せることで、自社のリソースを事業に集中させることができる、という、AWS、AWSのパートナーにとっても非常に嬉しい事例だと思います。